🦋 Changeset detected

Latest commit: ffe6158

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@ZeynelKoca is attempting to deploy a commit to the HyperDX Team on Vercel.

A member of the Team first needs to authorize it.

PR Review

• ⚠️ No guard against user deletion/editing of provisioned dashboards via API — deleteDashboard and updateDashboard in controllers/dashboard.ts have no check for provisioned: true. Users can delete or modify provisioned dashboards; they'll be silently restored/overwritten on next sync. Consider returning a 403 or warning when operating on provisioned dashboards, or at minimum document this as expected behavior.

• ⚠️ provisioned field exposed in API responses — the new provisioned: boolean field will appear in all dashboard API responses (including external API v2) without any changes to response serialization. If this is intentional, it's fine; otherwise, consider stripping it in output schemas.

• ⚠️ Coexisting duplicate names not reflected in unique index — the partial unique index (partialFilterExpression: { provisioned: true }) only enforces uniqueness among provisioned dashboards. User-created dashboards have no uniqueness constraint. The syncDashboards logic creates a provisioned copy alongside a user-created one with the same name, meaning users will see two dashboards with identical names in the UI. This should be documented in user-facing docs (it's in AUTO_PROVISION.md but not surfaced in the UI).

• ✅ Logic is otherwise clean: finally block correctly resets isSyncing on early returns, new: false correctly detects insert vs update, partial filter expression is backward-compatible with existing data, and test coverage is thorough.

PR Review

* ⚠️ **`updateDashboard` / `deleteDashboard` don't guard provisioned dashboards** → Users can modify or delete provisioned dashboards via the internal API (`findOneAndUpdate` and `findOneAndDelete` have no `provisioned: false` filter). Deletions are recoverable (next sync re-creates), but updates will be silently overwritten. Consider adding a guard or at least a warning log in those controllers.

* ⚠️ **`stopDashboardProvisioner` resets `isSyncing = false` unconditionally** → If a sync is in-flight during server shutdown, clearing `isSyncing` immediately allows the finally block to race with the shutting-down DB connection. Low probability in practice, but could produce noisy errors on graceful shutdown. Consider waiting for the in-flight sync or not resetting `isSyncing` in stop.

* ℹ️ **`$setOnInsert` redundancy** → `name`, `team`, and `provisioned: true` are already included by MongoDB from the filter on upsert insert; the explicit `$setOnInsert` block is redundant. Not a bug, just noise.

✅ Schema validation (DashboardWithoutIdSchema) correctly strips provisioned so users can't set it via create/update API endpoints. Index design (partialFilterExpression: { provisioned: true }) is correct. Test coverage is solid.

1. API guards for provisioned dashboards: Out of scope for this PR. Modifying the existing dashboard controllers changes the API contract and should be a separate PR. Deletions are self-healing (next sync recreates), and updates are overwritten on next sync. The GitOps source of truth is the file, not the database.
2. isSyncing in stop: The sync completes in milliseconds (a few MongoDB upserts). The 10-second graceful shutdown window is more than sufficient
3. $setOnInsert redundancy: Intentional. Explicit is better than relying on implicit MongoDB behavior